1. Field of the Invention
The present invention relates to computer programming, and deals more particularly with techniques for developing a graphical editor using an incremental development approach.
2. Description of the Related Art
Conducting business electronically using distributed networking environments such as the Internet—commonly referred to as “e-business”—is increasingly popular with business enterprises throughout the world. Providing e-business software—that is, software with which an enterprise provides its “electronic presence” in the e-business marketplace and conducts business electronically—can be a complex, time-consuming, and costly undertaking. Vendors such as the International Business Machines Corporation (“IBM”®) provide their customers with platforms and tools to assist in this process. Such platforms and tools must fulfill user's needs while being developed in a brisk-paced approach in order to remain competitive. (“IBM” is a registered trademark of the International Business Machines Corporation in the United States, other countries, or both.)
Today, tools for developing e-business software (as well other types of software) are commonly composed from many functional components. One of the main components of many tools is a graphical editor. Graphical editors present views of underlying domain models using graphical representations that include elements such as circles, boxes, lines, images, and icons. Graphical editors can be used for modeling things such as business processes, application models, or even user interface (“UI”) screens. Since graphical editors mainly interact with users, a key success factor of graphical editor design is to have an appropriate usability that simplifies the user interactions and meets the user needs.
Creating a graphical editor is not an easy task, and requires considerable interaction with usability analysts. Usability analysts are people who are concerned with defining the requirements for effectiveness, efficiency, and satisfaction with which the end users can achieve tasks when using an application. When defining these requirements, usability analysts often consult people such as media designers, domain modelers, and high-privilege user groups.
There are many different approaches in designing a graphical editor. One approach focuses on how to describe the requirements. When designing according to this approach, a story board is often used to describe snapshots of visual views and the relationship of the visual elements. However, this approach can only describe a high-level relationship between visual views, and seems insufficient when trying to describe the details of each visual element.
Another, more expensive, approach is to develop a prototype. A prototype will provide a product-like, high-level perspective of the editor's usability behavior, and can be used to depict some of the high-level requirements of the graphical editor. The prototype is normally developed in a fast-paced manner in order to reduce the development cycle, cut costs, and/or avoid addressing some of the technical details that cannot be resolved at that moment. A major drawback of prototypes, however, is that they only try to present the general idea of the editor, and the developed prototype code typically cannot be reused in development of the editor itself. In addition, the usability requirements captured in the prototype stage may not accurately reflect the needs of the developed product.
In another approach, which speeds up the development cycle, a framework is provided. The framework approach can be used in development of prototypes or in actual product development cycles, and can reduce a fair amount of coding time. However, this approach still requires considerable effort to create an actual implementation. Since this approach is somewhat inflexible, it requires cautious planning and proactive process control since normally, requirements can only be accommodated in the early stage of the development cycle. Unfortunately, this does not match the nature of usability analysis, which tends to be an iterative process.
Today, developing a graphical editor of a tool normally follows the framework approach and uses the so-called “model-view-controller”, or “MVC”, pattern. The MVC pattern consists of three kinds of objects. The Visual (“V”) object is the view representation in the graphical editor. The Model (“M”) object is the domain model that the visual object represents. Finally, the Controller (“C”) object defines how the user interface reacts to the user input. The MVC pattern has been applied to many different graphical editor frameworks.
As an example, the Eclipse Graphical Editing Framework (“GEF”) is sometimes used as a graphical editor development framework. (Eclipse provides an open-source framework that is commonly used for development of e-business applications.) GEF provides a set of application programming interfaces (“APIs”) for software developers to use and extend when developing their code. As discussed above, using this framework approach provides some benefits to reduce the development cycle; however the cycle is still not short enough. It also does not provide the flexibility to modify the editor when needed.
The above approaches are not fully effective for developing graphical editors because usability analysts do not have the capability to touch and feel the product in sufficient, representative detail in the early milestone or phase of a software development cycle. Using the current approaches, the most effective way to provide a graphical editor is to develop a full product and then allow the usability analysts to study the problems and fix those problems in the next development cycle. However, this after-the-fact approach may cause the failure of the product in the marketplace.